home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000824-20010305 / 000153_news@columbia.edu _Thu Dec 28 17:12:34 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by monire.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA11865
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Thu, 28 Dec 2000 17:12:34 -0500 (EST)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA13264
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 28 Dec 2000 17:12:33 -0500 (EST)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id RAA02272
  10.     for kermit.misc@watsun.cc.columbia.edu; Thu, 28 Dec 2000 17:12:47 -0500 (EST)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: fdc@columbia.edu (Frank da Cruz)
  13. Subject: Re: A wish for the FTP-client
  14. Date: 28 Dec 2000 22:12:46 GMT
  15. Organization: Columbia University
  16. Message-ID: <92gdsu$26u$1@newsmaster.cc.columbia.edu>
  17. To: kermit.misc@columbia.edu
  18.  
  19. In article <5VP2SCqS3328@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
  20. : In article <92g92f$s9j$1@newsmaster.cc.columbia.edu>,
  21. : fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  22. : >    "...
  23. : >    mktime() normalizes  the supplied tm structure" -- applies timezone
  24. : >    conversions, etc.  The problem there is, of course, we don't know, and
  25. : >    have no way to find out, the server's timezone, and even if we knew it,
  26. : >    what the rules are to convert to our own.  The struct tm is *already* in
  27. : >    GMT/UTC, and should not be converted to it again.
  28. : > 
  29. : > Thus the resulting file date won't be what you want.  I think the object
  30. : > of copying the server's MDTM is so update can work in both directions.  If
  31. : > we use mktime(), I think the result will have up to 24 hours of randomness
  32. : > added or subtracted.  Am I missing something?
  33. :
  34. :     I face this problem daily, at 0300 during mirroring operations. As
  35. : Frank notes well, TZ material makes a mess of trying to reproduce UTC stamps
  36. : from FTP information. What I do, and what works reasonably well, is use what
  37. : FTP itself reports in a LIST command (parse according to remote server
  38. : syntax) which is what it thinks the local time/date of the file is. I then
  39. : make the client side report the same time/date at user level. This makes
  40. : local and remote systems "appear" to yield identical file listings.
  41. :
  42. Given the ability to parse an "ls -l" listing, this approach works great when
  43. (a) client and server are in the same timezone, or (b) the client knows what
  44. timezone the server is in and knows how to "pre-unadjust".  But in the
  45. general case, the client has no clue as to the server's timezone or daylight
  46. savings rules, and therefore hasn't a prayer of compensating for mktime()'s
  47. adjustments.  Also, parsing LIST responses is not a general solution since
  48. the server might not be UNIX, or might be running some kind of "improved"
  49. ls, or whatever.
  50.  
  51. In truth, FTP protocol and UNIX APIs leave a lot to be desired, especially
  52. when the holes coincide.
  53.  
  54. - Frank